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ABSTRACT 



The Naval Postgraduate School (NPS) is currently involved 
in a long term project to investigate and develop real-time 
software for command and control of Autonomous Underwater 
Vehicles (AUV) . In support of this goal, NPS is currently 
designing and fabricating a testbed AUV. 

This thesis describes the design, development and testing 
of a real-time scheduling software package to act as the top 
layer of control software for the AUV. 

Also discussed are the various real-time scheduling 
policies available along with the features of the assigned 
operating system that allow implementation of the scheduler. 
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I . INTRODUCTION 



A. GENERAL 

The Naval Postgraduate School (NPS) is developing an 
autonomous undervater vehicle (AUV) - an untethered, 
intelligent, robot submarine. The current AUV, AUV-II, is the 
second in a series of three vehicles to be built. It has been 
designed as a testbed for research in adaptive control, 
mission planning and execution, data collection and analysis, 
and the uses of various sensors. 

AUV-II is driven by a pair of 4" propellers and four 
hovering thrusters. These and the eight control surfaces used 
allow for a high degree of vehicle control. The vehicle's 
sensors include four sonars, a depth cell, and a speed 
indicator. Positional data is provided by three on-board 
gyroscopes and a magnetic compass. 

The on-board computer hardware is centered around a twelve 
slot G-96 bus supplied by the GESPAC corporation [DIBBLE 90]. 
The bus hosts a Motorola 68030-based processor board along 
with 2.5 Megabits of RAM and 4 Megabytes of EPROM. 

Five other slots are dedicated to a 200 Megabyte hard disk 
drive, parallel and serial communication ports, an analog-to- 
digital channel from the sensors, and a digital-to-analog 
channel to the effectors. The remaining slots are expected to 
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be used for additional memory and Transputer boards. Figure 
1.1 [HEALY 90] shows the internal and external configurations 
of AUV-II. 





Figure 1.1 Internal and External Configurations of AUV-II 
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The computer uses the OS-9 operating system developed by 
MICROWARE for GESPAC [GESPAC 88]. OS-9 is a complete operating 
system having a file system, native compilers, a built-in 
editor, the ability to support local area networks, multi- 
tasking abilities, real-time features such as timers, process 
creation and deletion primitives, process priority 
assignments, and signal sending and receiving structures. It 
has the added advantage of having been used in prior AUV 
research [HEALY 90]. The AUV-II project is ongoing, and has 
had many successful trials in the NPS pool. 

B. COMPUTATIONAL REQUIREMENTS OF THE AUV 

For successful mission completion, AUV-II must be able to 
execute a complex set of both periodic and aperiodic processes 
(or tasks) that may have widely varying attributes such as 
variable execution times, frequencies and response times. 
These tasks may include: mission planning, path planning, 
guidance, effector control, sensor control, collision 
avoidance, and data collection [HEALY 90] . The inter- 
relationship of these are shown in Figure 1.2 [HEALY 90]. As 
can be seen in Fig. 1.2, the operator starts, and controls the 
entire mission. The focus of this thesis is to provide real- 
time control for that mission, consisting of many tasks with 
widely differing computational requirements. For example, 
block 8, collision avoidance, is an aperiodic task - since 
obstacles cannot be predicted - while block 6, navigation. 
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predicted - while block 6, navigation, requires periodic 
computer attention. Also, while both block 6 and block 5, 
sonar, are periodic, their respective periods are quite 
different; sonar having the higher frequency. Since obstacle 
avoidance has not yet been completely integrated in the AUV, 
this thesis concentrates on periodic task scheduling and 
execution. Once the parameters of aperiodic tasks have been 
finalized, it should require very little extra work to 
incorporate aperiodic scheduling into the existing control 
software. A more detailed analysis of Figure 1.2 may be found 
in [HEALY 90]. Computational resources must be used such that 
all tasks complete execution within their respective periods, 
or, in real-time terms, meet their deadlines in a predictable 
and reliable manner regardless of the difference in their 
attributes . 

In the current vehicle software, all processes are 
executed in an infinite loop operating at roughly 10 Hz. 
Although this is adequate for the simple missions now being 
executed, it lacks the necessary sophistication for the more 
complex missions planned. These missions may include, for 
instance, tasks that are required to be executed at different 
frequencies. For example the sonar system operates at 5 Hz 
while the motion control loop operates at 10 Hz. 

A recent study [BIHARI 90] of the processing requirements 
of this project delineates the necessity of an efficient, hard 
real-time scheduler to ensure the correct functioning of the 



4 



AIJV DATAFLOW DIAGRAM 
Baseline Syslein 




Figure 1.2 



Data Flow Diagram for the AUV 
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vehicle. A scheduler is the top layer of AUV-II software, 
which coordinates the task set to ensure that all process 
deadlines are met in a reliable and predictable manner. The 
scheduler must be able to, at a minimum, access at least one 
accurate time base, run processes at specified points in time, 
support synchronous and asynchronous communications between 
processes, and place bounds on the response time of aperiodic 
processes and events. An important attribute of a scheduler is 
how it responds to an overload condition in which it is not 
possible for all tasks to meet their deadlines because they 
exceed the net processing reserves available. Overload may 
occur in two ways, transient or sustained. Transient overload 
is caused by the execution of an aperiodic event that requires 
the suspension of one or more periodic events. Sustained 
overload is caused by unexpected increases in process 
execution time such that the processor load exceeds its 
resources. A scheduler must be able to handle overload 
conditions in a stable manner. For a scheduler to be 
considered stable, two requirements must be met. The first 
being that a subset of the most critical tasks aways meet 
their respective deadlines. The second is a quick return to 
normal operation once the overload condition has passed. 



C. OBJECTIVES OF STUDY 

OS-9 scheduling policy cannot provide hard real-time 
performance without the addition of a control layer of 
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software to schedule the task sets required by the AUV. 
Therefore, the main objective of this study is to develop a 
real-time scheduler that meets the following requirements; 

1. It must use only OS-9 real-time primitives, with no 
modifications to the operating system. 

2. It must be capable of maintaining a relatively high 
processor utilization without missing task deadlines. 

3 . It must be able to support task sets with varying 
characteristics . 

4. It must remain stable under transient overload. 

Rapid recovery after elimination of the overload is of 
prime importance in this case. 

5. It must remain stable and degrade gracefully under 
sustained overload. In this case, the important feature 
is meeting the deadlines of a subset of more critical 
processes while sacrificing those that are less 
critical . 

6. Since the scheduler will be implemented on an already 
functioning vehicle, it must be able to integrate and 
communicate with the existing motion control software 
with as few modifications as possible to that 
software. AUV software modules are being designed by 
different project members that have little knowledge of 
the scheduler; therefore, it must be simple to use and 
maintain. In order to simplify the use of the scheduler. 
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a graphical interface is being developed and is the 
subject of a follow-on thesis. 



D. METHOD OF APPROACH 

This thesis deals with the implementation of a theoretical 
method of real-time scheduling into a practical working 
scheduler robust enough to handle the various situations that 
are to be expected on a functioning vehicle. As such, not only 
must the scheduler meet the requirements of the selected 
scheduling policy, but also account for the real world 
conditions such as process switching overhead and variable 
process execution times that will degrade performance below 
theoretical values. It was necessary to determine what 
processor loads were feasible and what characterization of 
processor set provided the required performance. To facilitate 
this implementation the following steps were taken; 

1. Selection of a suitable scheduling policy. 

2. Implementation of the policy using OS-9 dependent 
resources. 

3. Experimental determination of the available utilization 
and observation of scheduler stability under various 
loads and task set characteristics. 
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All programming for this project was done using the 
resident C compiler provided by MICROWARE, and is closely tied 
to the OS-9 operating system [MICROWARE 87]. Porting to 
another system would require extensive modification of the 
scheduler. 

This project successfully implemented a scheduling layer 
of software that can determine if a given periodic task set 
can be successfully scheduled to deliver processor utilization 
exceeding 85%. Aperiodic tasks can be scheduled on a more 
limited basis by treating them as periodic events with a 
period equal to infinity. The improvement over the passive OS- 
9 policy is clearly demonstrated in a later chapter of this 
thesis . 

E. THESIS ORGANIZATION 

Chapter II presents a discussion of various real-time 
scheduling policies and outlines the reasons for using rate 
monotonic scheduling for AUV-II. Chapter III is a more 
complete and detailed study of rate monotonic scheduling 
theory. Chapter IV details the implementation of rate 
monotonic scheduling using the OS-9 operating system. Chapter 
V presents the methods and experiments used to determine 
scheduler performance and veracity. Chapter VI summarizes the 
results of this study and describes future directions for 
study . 
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II. AN OVERVIEW OF REAL-TIME SYSTEMS 



A. GENERAL 

A real-time system is defined to be one in which the 
various processes adhere to time constraints determined by the 
application. Although real-time systems are often associated 
with extremely fast processing speeds, this is not an accurate 
interpretation. A real-time system refers to the timely 
occurrence of events and the intervals involved may range from 
microseconds to years [LEVI 90]. 

Real-time systems can be loosely divided into two 
categories, hard deadline and soft deadline systems. Hard 
deadline systems are those where the missing of a process 
deadline is catastrophic. Conversely, while making all 
deadlines is desirable on a soft deadline system, missing one 
is not a fatal error [LEVI 90]. 

Assigning priorities to different concurrent processes is 
a common mechanism used to share computational resources in a 
real-time system. Based on how the priorities may be assigned, 
real-time systems can be further classified as fixed priority 
systems in which all process priorities are fixed at run time, 
or dynamic priority systems in which priorities can be changed 
during execution. Rate monotonic scheduling [LIU 73] is an 
example of a scheduling policy that uses fixed prioritization. 
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Conversely, earliest deadline scheduling policy [LEVI 90] 
makes use of dynamic scheduling for successful operation. If 
these two types of systems are combined, a hybrid is achieved 
that is known as a mixed priority system [LEVI 90]. 

B. OS-9 SPECIFIC REAL-TIME PRIMITIVES 

The OS-9 operating system contains a wide range of real- 
time primitives that can be used to implement a functioning 
real-time scheduler. This section describes these primitives 
in a general fashion; a detailed listing of the commands and 
their functions may be found in Appendix D. 

OS-9 is, inherently, a multi-tasking system. This is 
demonstrated by the process priority assignment embedded in 
OS-9. Processes may be assigned a priority from one of 65,536 
separate priority levels when they are forked into existence. 
The forked processes are placed on a ready-to-execute queue in 
direct order of their priority. The process at the head of the 
queue is executed for one or more ticks. A tick is the 
smallest unit of time the system recognizes and may be set by 
the system operator for a duration as low as 10 milliseconds. 
Once a process has started executing, it will execute until it 
has completed execution or until the end of the current tick. 
All non-executing processes have their priorities increased by 
one for each tick spent in the ready-to-execute queue, a 
process referred to as aging [MICROWARE 87]. Aging is normally 
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used to ensure that all processes eventually receive the 
attention of the processor regardless of their priority .Once 
a process has executed, it is reduced to its original 
priority. The queue is checked every tick to determine which 
process has the highest priority and, therefore, the right to 
the processing unit. Process switching times are on the order 
of 50 microseconds [DIBBLE 88]. 

OS-9 uses this queue and various commands to support 
real-time operations. These commands include timing commands 
that check absolute, relative, and elapsed times. These 
commands all have a resolution of a tick. System commands are 
also provided that allow processes to suspend themselves. A 
suspended process is removed from the ready-to-execute queue 
and does not age until reactivated. Reactivation can be 
accomplished by either an elapsed time counter, an absolute 
time event or upon the receipt of a signal from another 
process. Signal sending and receiving mechanisms are closely 
coupled with process suspension and are used to provide 
interprocess coordination and timing. Signals can be used to 
either wake up or kill a process. Customized signals are also 
supported. Another class of primitives that help in the 
development of real-time systems are the ones that allow for 
access to process identities, states, and parameters [GESPAC 
88 ] . 
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C . IMPLEMENTATION 



The rate monotonia scheduling algorithm was chosen as the 
method to implement upon AUV-II, due to it being the optimal 
fixed priority scheduling algorithm [LIU 73]. While dynamic 
scheduling can increase overall processor utilization, it is 
much more difficult to implement in a practical fashion due to 
the problem most operating systems have in arbitrarily 
reassigning priorities during execution [LIU 73]. Rate 
monotonic scheduling is presented in greater detail in the 
following chapter. 
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III. RATE MONOTONIC SCHEDULING THEORY 



A. INTRODUCTION 

The rate monotonic scheduling (RMS) algorithm was chosen 
as the basis for the scheduler on AUV-II; its practical 
aspects having been recently analyzed [SHA 90] . RMS uses the 
following model of the workload. 

1. The workload must consist of independent processes; an 
independent process being one that does not require the 
execution of any other process to function. 

2. All process priorities are fixed at the time of 
execution. 

3. The system must provide for pre-emptive execution; i.e. 
higher priority processes will interrupt the execution of 
lower priority processes. 

Given these conditions, RMS guarantees that in the worst 
case conditions, all deadlines will be met for at least a 
69.3% processor load. Processor load is defined to be the sum 
of the execution times of each process divided by the 
respective period of each process. This function is shown in 
Equation (3.1) . 
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(3.1) 




wheie 

X is the piocessoz load 

is the execution time of process i 
is the period of process i 
n is the number of processes 

The above mentioned limit is known as the Liu-Layland bound 
named for the two men who derived it [LIU 73]. 

B. PERIODIC TASK SCHEDULING 

One of the most important attributes of a task set is its 
phasing; the order and timing in which the various tasks are 
to be executed. The Liu-Layland bound represents the worst 
case task set phasing; i.e. one with the maximum of number of 
task preemptions. A system may be able to support a higher 
processor utilization if the task set phasing is more 
favorable. Two theorems have been developed to determine if 
the higher processor load is schedulable [LEHOCZKY 89]. For a 
task set to be considered schedulable, all tasks must meet 
their respective deadlines under all task set phasings. 

The first method used in determining schedulability is 
given by Equation (3.2) [SHA 90]. 
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(3.2) 



T„ 

where 

is the execution time of process i 
is the period of process i 
n is the number of processes 



The upper limit of 1.0 decreases monotonically until, as 
n approaches infinity, the right side of Equation (3.2) yields 
the Liu-Layland bound of 0.693, or, 69.3%. If the processor 
load is less than or equal to this bound, the task set is 
always schedulable. The second method for determining 
schedulability is more complex, but more exact, and is given 
in Equation (3.3). The term scheduling points in Equation 
(3.3) refer to the arrival times for all processes in the task 
set within the longest period in the task set. For example, a 
task set consisting of four tasks periods 4, 6, 12, and 25 
units, would have the following set of scheduling points: 4, 
6, 8, 12, 16, 18, 20, 24, and 25 [SHA 86]. 



Vi, l^i^n 



IT^ 






1.0 

j=l ■‘■■‘■k 

(k, 1) 
where 



(3.3) 



Cj is the execution time of process j 
Tj is the period of process j 

is the collection of scheduling points for the task set 

T . 

1 is the ratio of I — 
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Equation (3.3) is evaluated for the entire set of 
scheduling points and the results compared to the value 1.0. 
If any of these values are less than, or equal to, 1.0, the 
task set is always schedulable under RMS. Once schedulability 
has been determined, RMS assigns a fixed priority to each 
process. This assignment is in inverse proportion to the 
period of the process; the shorter the period, the higher the 
priority. Once priorities have been assigned, the processes 
can be executed using the preemption functions provided by the 
system. Although neither of the two methods of determining 
schedulability guarantees more than a 69.3% utilization under 
worst case conditions, average case utilization values can 
range from 85-90%, well above the Liu-Layland bound. This 
higher utilization value is attributable to the concept of the 
critical instant [SHA 90]. A critical instant is one in which 
all processes are initiated at the same instant, thus creating 
the maximum number of preempted processes. It has been 
determined that the higher the number of critical instants, 
the lower the achievable utilization [SHA 86] . This then can 
be used to predict worst case performance and, by judicious 
selection of task periods (assuming some flexibility in period 
selection), a task set can be 'tuned' to achieve high 
utilization. 

C. APERIODIC TASK SCHEDULING 

Aperiodic tasks are tasks that appear on an irregular. 
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unpredictable basis. An example of an aperiodic process for 
the AUV-II would be collision avoidance. RMS services 
aperiodic tasks using a sporadic server; that is, a mechanism 
that executes the task if a request is sent from the aperiodic 
task, and if there are sufficient reserve computational 
resources to process the request. In other words, the system 
workload must be low enough that the aperiodic event can be 
served without disrupting the periodic task set. Provisions 
must be made for the case where the aperiodic event is crucial 
and therefore needs to be able to preempt all, or part, of the 
periodic task set [SHA 90]. 

C. PERIOD TRANSFORMATION 

RMS always guarantees that a certain subset of the task 
set will meet their deadlines under worst case conditions. 
This subset is known as the critical set. Since process 
priority is in inverse proportion to period lengths, under 
some circumstances, a process with a long period and lower 
priority may serve a more critical function than a process 
with a shorter period and must be included in the critical 
subset [SHA 90]. 

This problem is solved using a technique known as period 
transformation. This method requires splitting the critical 
process into two logical parts, each one having 1/2 the worst 
case execution time of the process and 1/2 the requested 
period. Priority is then assigned to the process according to 
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the reduced period length and, thus, elevated. Once task set 
execution begins, the critical process executes 1/2 of its 
worst case execution time in the first half of its period and 
then suspends itself. The other half of the execution comes 
during the second half of its main period. This is shown in 
Figure 3 . 1 [SHA 90] . 



0 T/2 T 







FIRST PART 




SECOND PART 




OF PI 
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Figure 3.1 Time Line Showing Period Transformation 

Given the limitations of the OS-9 operating system, some of 
the features of RMS were more difficult to implement than 
others. The RMS attributes implemented in this thesis include 
schedulabilty checking, periodic process serving, a limited 
ability to service aperiodic tasks, and the ability to remain 
stable under overload conditions. The details of this 
implementation are described in the next chapter. 



19 



IV. AN IMPLEMENTATION OF RMS ON OS -9 



A. GENERAL 

The scheduling software, as implemented on the GESPAC 
computer, consists of five logical parts. These are: the 

scheduler startup process, initialization, schedulability 
analysis, the master scheduler, and the modifications that 
need to be made to the processes called by the scheduler. 

Due to the limitations of the OS-9 operating system, and the 
specification that no modifications be made to this system, 
this was a non-trivial problem. As mentioned before, the 
scheduler is highly OS-9 dependent; therefore, there has been 
an effort made to highlight all non-standard C commands used 
in order that future modifications to the scheduler can be 
accomplished without excessive difficulty. Figure 4.1 
illustrates the sequence of steps in the scheduling software. 
These are more fully explained in sections B through F of this 
chapter. 



B. SCHEDULER STARTUP 

To function correctly, the run time module must have the 
highest priority on the system. This is due to its function as 
the coordinator of the AUV-II software; in other words, it 
must not be preempted by a called process while it is 



20 




Figure 4.1 Step Sequence of Scheduling Software 
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executing the scheduling process. In the OS-9 operating 
system, run-time priority is set by the command, os9forkc, and 
cannot be changed in the process itself. Thus, it was 
necessary to develop a small calling program to establish the 
scheduler's initial high priority. It first spawns the 
scheduler and then suspends itself until the completion of the 
mission. It should be stated that all processes to be called 
using the os9forkc command are required to have an executable 
module located in a directory available to the scheduler. 
Since they will be called by OS-9 commands, the called 
processes should not be linked together during the compilation 
process . 

As stated in Chapter II, OS-9 provides for 65,536 distinct 
priority levels. It was arbitrarily determined that a priority 
level for the scheduler of 62,000 would be appropriate. This 
is high enough to preempt all other system processes, but 
still leaves some higher priorities for emergency processes 
such that the scheduler would be deliberately interrupted. 
This priority can be easily changed in the startup module. The 
source code for the startup module is located in Appendix A. 

C. SCHEDULER INITIALIZATION 

Scheduler initialization begins by entering task set 
parameters. The first parameter is the number of processes in 
the task set. Once this has been entered at the keyboard, a 
loop is started that brings in the names of the processes. 
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their periods and execution times. Although this is currently 
entered manually at the keyboard, it may be changed to a file 
input/output system for implementation on the vehicle if 
desired. Process execution times can be obtained in two ways; 
the first is direct input by the system operator, the second 
is done by the scheduler as it forks slightly modified 
versions of the modules and times their lengths of execution. 
This procedure is outlined in Appendix B. 

Once the task set parameters are available to the 
scheduler, the program sorts the processes by period from 
shortest to longest with ties broken arbitrarily. This is 
accomplished by a standard heap sort routine. This sort also 
establishes the relative priorities of the process from 
highest to lowest in inverse proportion to the length of the 
respective periods. 

Absolute priorities must be assigned to each process 
before they can be forked off for execution. Due to the 
inherent conflict between the fixed priority requirements of 
RMS and the automatic aging of non-executing processes as 
implemented by OS-9, it became necessary to space process 
priorities far enough apart to ensure that no processe 
priority could overtake another. This scheme successfully 
negates the run-time aging of process priorities inherent to 
OS-9 and gives the illusion of fixed priorities to the 
scheduler. 

Absolute priority assignment is accomplished by first 
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finding the least comition multiple of the periods of all 
processes in the task set. Once the least common multiple is 
established, priorities are set using Equation (4.1). 

<nc,) 

p, = p - [_i;i LOU 

1 a j 

j'l 

where (4.1) 

Pj is the processes priority 
Pq is the highest priority process 
Cj is the execution time of process j 
Tj is the period of process j 

LCM is the least common multiple of all periods 

The process with the shortest period, and therefore the 
highest priority, is assigned a priority of 60,000. This is P 
and was chosen to be well below the priority of the scheduler, 
while being large enough to permit a wide range of priorities 
under it. To illustrate the use of Equation (4.1), consider a 
task set consisting of two processes. Process one has a period 
of 50 ticks, and an execution time of 12 ticks. Process two 
has a period of 100 ticks, and an execution time of 15 ticks. 
Process one is automatically assigned a priority of 60,000, 
the maximum available. Process two has its priority assigned 
by subtracting the product of both execution times, a value of 
180, and dividing it by the product of the periods, a value of 
5000. This quotient is 0.036 and is multiplied by the LCM of 
the two periods, 100, giving a final value of 3.6. This is 
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rounded up to the next highest integer, 4.0, and subtracted 
from the value of the highest priority process. Process two, 
then, is assigned a priority of 59,996. 

Although Equation (4.1) gives the correct absolute spacing 
between process priorities, under certain conditions, it can 
cause abnormally wide spacings between the priorities. This is 
usually caused by a large number of processes with different 
periods resulting in a large least common multiple. An example 
of this is given by considering two, two-process sets. Set one 
has two tasks with periods of 50 and 100 while set two has two 
task with periods of 51 and 100. Although these two sets are 
virtually identical, the first has a least common multiple of 
100 while the second is 5100. When these least common 
multiples are used in Equation (4.1) , the spacings would place 
the priorities of the second set much farther apart than in 
the first set. If there were an infinite supply of priority 
levels, this would be no problem, but, as mentioned earlier, 
OS-9 supplies only 65,536 priorities which are quickly spanned 
by a reasonably large task set. The solution to this problem 
was to first detect the large spacings and then reassign them 
the priority equal to the priority of next highest priority 
process minus the value equal to the number of ticks of the 
longest period in the task set. This value is theoretically 
the most any one process could age before it is executed. This 
two pronged approach to prioritization has proven to be 
successful in all tests and experiments using the scheduler. 
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There were no recorded cases of a lower priority process 
overtaking a higher priority process. 



D. SCHEDULABILITY T^ALYSIS 

The schedulability of a task set uses the process 
described by theorem three [SHA 90]. The steps are described 
in a series of Equations (4. 2-4. 5) shown below. 

The first step, given in Equation (4.2), is to determine 
the processor demands made by the task set as a function of 
time [Lehoczky 89]. The second step is to normalize the 
results to achieve a value between 0.0 and 1.0. This 




where 



fV^it) is processor load as a function of time (4.2) 
Isisn 

n is the number of processes 6 the task set 
Cj is the execution time of process j 
Tj is the period of process j 
t is time as a continous variable 



is accomplished in Equation (4.3) by dividing by time and is 
simply an intermediate step in the process of converting the 
results from continuous to discrete values. The next step is 

L^it) = W^{t)/t (4.3) 
given is Equation (4.4) where the continuous time variable, t. 
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is converted, by the computation of scheduling points, to the 
discrete variable, s, as discussed in Chapter II. 

Li = min(0 ^ Si ^ r_j)Lj(Sj) 

where (4.4) 

Si are the various scheduling points 



The final step is a check to determine if Li has a 
value less than or equal to 1.0, as shown in equation (4.5). 

Li ^ 1.0 (4.5) 

If the task set meets schedulability requirements, a 
confirmation message is sent to the system operator and the 
master scheduler initiated. If the task set does not meet 
schedulability requirements, an error message is sent to the 
operator and the scheduler is suspended until a workable task 
set is developed. 



E. THE SCHEDULER 

Once priorities have been calculated and schedulability 
determined, scheduling analysis is complete and task set 
execution may begin. The analysis and execution functions are 
currently part of the same software module. This means that 
analysis is done in the field prior to the beginning of the 
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mission. Since the task set has presumably been checked before 
the various field tests, only the executable module needs to 
be ported to the AUV, with the various values generated by the 
analyzer being read from a disk file prior to the start of a 
mission. This will require some minor modifications to the 
scheduler. 

The first step is the creation of the individual processes 
that are listed in the task set. This is done using the OS-9 
commands osSforkc and os9exec. The original program 
specifications had called for a scheme that created a process 
at the start of each period, executed the process and then 
killed the process prior to the end of the period. This proved 
to be unworkable when it was found that the procedure for 
creating a process took a random time varying between 220 and 
340 milliseconds. Since at least one vehicle control module 
was required to run at 10 Hz, this method was fatally flawed. 
A more sophisticated approach was developed that entailed 
creating each process once, at the beginning of the scheduler 
module, and then, after execution, suspending the process 
until receipt of a signal from the master scheduler. This 
method reduced the task switching time to 55 microseconds, 
some 400,000% faster than the original method. The second 
method had the added benefit of reducing the amount of 
processor time conducting the 'garbage collection' required in 
the creation and killing of processes. 

As the scheduler creates each process, two entries are 
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made in the table that is the heart of the scheduler and is 



shown in Figure 4.2. 



PROCESS ID TIME UNTIL NEXT 

NUMBER EXECUTION 




Figure 4.2 Table Data Structure with Sample Entries 

The first column in the table is the identification number 
of each process. The second column is the next time to 
execution for each process. The master scheduler enters an 
infinite loop, once all processes have been created and placed 
on the ready-to-execute queue. Once in the loop, the scheduler 
scans the second column for zero values which indicates that 
the process is ready to start execution. If a zero entry is 
found, the process identification number is recorded and the 
scan continued through the table. Once all entries in the 
table have been checked, a time stamp is taken and the flagged 
processes are sent wake up signals from the scheduler. When 
the last signal has been sent, another time stamp is taken and 
the elapsed time from the start of the signaling procedure to 
the end is recorded and all signaled processes have their next 
time to execute entry reset to their original period. All 
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table entries then have the elapsed time subtracted from the 
second column of the table. This is done to prevent scheduler 
overhead from affecting the scheduling process. The scheduler 
then scans the second column for the smallest value present. 
This value is subtracted from all second column entries and 
the main scheduler is then suspended for this length of time 
to allow the called processes to begin execution. The possible 
conflicts between the children processes are resolved through 
the preemption allowed by the priorities assigned. This entire 
process, in psuedo-code, is illustrated in Figure 4.3. 



While (true) 

scan table for zero entries; 
if entry = 0, 

record id number; 
take time stamp #1; 

for i=0 to m /* m = number of processes to be 

signaled */ 

find process (i) id number; 
signal process (id number); 
end for loop 
take time stamp #2; 

adjustment = time stamp #2 -time stamp #1; 
for i = 0 to n /* all processes */ 

table entry (i) = table entry (i) - adjustment; 
scan table for smallest entry (in ticks) ; 
for i=0 to n /*all processes */ 
table entry (i) = table entry (i) - smallest entry; 
suspend scheduler for smallest entry ticks; 
end while; 



Figure 4.3 Psuedo Code for Signaling Process 
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During program development, the control loop was modified 
from an infinite loop to a finite loop controlled by the 
number of signals sent. It is recommended that onboard the AUV 
it remain an infinite loop with logic implemented to halt the 
loop from an outside source such as a keyboard interrupt or a 
time signal from the system clock or an elapsed time counter. 
This will allow for a more graceful exit from the program than 
the currently required rebooting of the system. A copy of the 
source code for the scheduler is found in Appendix B. 

F. MODIFICATIONS OF CALLED PROCESSES 

One goal in the original specifications for the scheduling 
software was that the other software modules would not have to 
be modified, that they could run 'as is.' This led to the 
original plan of create/execute/kill discussed earlier. When 
this proved unworkable, it was determined that a minimum 
amount of modification would have to be made in the other 
software modules in the system. These were designed to be 
quickly and easily installed in only a few minutes per module. 

To implement the first modification, it is necessary to 
determine the sections of software that are to be executed 
each period versus those that are to be only run once, such as 
process initialization. Once these sections are identified an 
infinite while loop is installed around them. The second 
modification is to install the signal catching commands in the 
loop between the last local line of code and the end of the 
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infinite while loop. These modifications are demonstrated in 
Figure 4.4. The command most suitable for this is the OS-9 



main ( ) 

{ 

initialization commands; 



while (1) 

{ 

repeated commands ; 



) 



wait ( ) ; 
exitO ; 



Figure 4.4 Modifications to Called Processes 

command wait() with no parameters. If it becomes desirable to 
return data or instructions back to the parent process, the 
OS-9 command exit() could be used. The wait() command suspends 
the child process (removes it from the ready-to-execute queue) 
until it receives a signal from the scheduler. During normal 
execution only two signals would be sent: a *1.0' to wake the 
process up, or a '0.0' indicating that the process is to be 
killed and its allotted memory returned to the system. The 
'0.0' is normally sent at the end of the mission to ensure a 
graceful termination of the scheduler. 

The emphasis on the graceful conclusion of the scheduler 
is based on practical experience on the OS-9 system. When a 
process finishes without an exit() command, the process 
identification table and the processes allotted memory remain 
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allocated by the system until the system is rebooted. It takes 
surprisingly few of these to fill and fragment the system 
memory. When the system is in this condition it will continue 
to attempt to function normally, but no processes will 
execute. This is annoying in a PC-based machine, and possibly 
dangerous to an operating vehicle. 

The last modification is used if the operator intends to 
allow the scheduler to measure the execution times of the 
processes. Since the time only needs to be measured over one 
execution of the process the infinite loop is removed and the 
wait() command is replaced with the exit() command. The 
modified process is named the same as the original process 
with the letter 'a' appended to it. As with the original 
process a executable module must be available to the system. 

G. APERIODIC EVENTS AND PERIOD TRANSFORMATION 

Aperiodic events are handled by the scheduler in the 
current implementation by treating them as a periodic event 
with an infinite period. This method assumes that aperiodic 
events can be sent a wake up signal by a process other than 
the scheduler, whereupon it executes in the same fashion as a 
periodic event. Upon completion of the aperiodic event, the 
process suspends itself until signaled the next time. A more 
sophisticated approach would require modifications to the 
timing table in the master scheduler and the prioritization of 
the processes. This would entail marking the aperiodic events 
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with a flag and then schedule them in the same manner as 
periodic events with the proper priorities. The next step is 
done while scanning the table for executable processes and 
would require the addition of logic to check for the flag on 
aperiodic events and only signal them if circumstances 
warranted . 

Period transformation was not implemented in the current 
scheduler due to limitations in the OS-9 operating system. To 
function correctly with a minimum of modification to the 
called processes, a method is needed to not only wake up the 
called processes from the master scheduler, but also to 
suspend the called processes. This is not possible; although 
a method has been derived in which period transformation could 
be implemented on, at least, a limited basis. This method 
would require that extensive modifications be made to the 
called processes and is beyond the scope of this study 
[SHUKLA 91] . 

Upon the completion of the scheduler software development, 
numerous tests and experiments were conducted to confirm the 
scheduler's veracity, reliability and limitations. These 
results are reported in the next chapter of this thesis. 
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V. EXPERIMENTS AND RESULTS 



A. GENERAL 

Once the scheduler was written, it was necessary to devise 
methods to ensure the scheduler's veracity and to demonstrate 
the improvement it offered over passive OS-9 as installed. It 
was also necessary to determine what processor loads it was 
able to effectively schedule, and how various task sets 
affected the scheduler performance. These results could then 
be used to fine tune task sets for the desired performance. 
Lastly, because the scheduler is implemented on a functioning 
vehicle, real world events were simulated by constructing task 
sets of random length execution times. 

Task sets were constructed of identical dummy processes 
consisting of C-language program headers combined with the OS- 
9 primitives required to send and receive signals. Data was 
gathered and sent to data files for later analysis in such a 
way as to not interfere with the execution times of the 
processes. Execution times were controlled by varying a timing 
loop in the individual processes. 



B. SCHEDULER VERIFICATION 

To verify scheduler performance, it was first necessary 
to show that the scheduler met the theoretical requirements of 
RMS. These requirements included pre-emption of lower priority 
processes by higher priority processes and a reliable means of 
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meeting process deadlines. The dummy tasks were modified in 
such a way that the start and stop times of execution were 
recorded. At the end of the sample run, these values were 
written to a file for analysis by hand. The results of a 
sample run with four tasks in the task set are shown in Figure 
5.1 as a time-line similar to the time-lines found in [SHA 
90] . 
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Preemption can clearly be seen as process PI, the process with 
the highest priority, forces the delay of all other processes 
in the set until it has completed execution. Likewise, P2 
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delays all processes, save PI, until it has completed. It is 
also clear that all processes met their assigned periods. 
Although this example has only four tasks, it demonstrates 
that the scheduler meets the theoretical requirements of RMS. 
Other sample runs confirm these results for sets with a larger 
number of processes. 



C. IMPROVEMENT OVER OS-9 

OS-9 is advertised as a multi-tasking operating system, 
that supports real time operations [MICROWARE 87]. A test to 
show that a separate scheduler was needed to improve 
performance above that provided by OS-9 as implemented was 
required. The test consisted of two tasks sets, both with six 
processes running at 10 Hz. The first set was executed using 
OS-9 alone; the other using the scheduler software developed. 
Scheduler breakdown was measured as the percentage of missed 
deadlines. Missed deadlines were determined by comparing the 
number of signals sent vice the number of signals received by 
each process. All graphs have the percentage breakdown on the 
abscissa and the percentage of processor load on the mantissa. 
As shown in Figure 5.2, OS-9 began missing deadlines at 
processor loads of 30% while the implemented scheduler does 
not miss a deadline until the 90% point, a clear improvement. 
The poor performance of OS-9 was expected, as it implements no 
real-time structure, but, rather, the primitives used to 
construct those structures. 
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% processor load 

Figure 5.2 OS-9 versus RMS Performance 



D. PROCESS LOAD VARIATIONS 

In order to ensure an effective scheduler on-board the 
vehicle, experiments were conducted by varying task set 
parameters to test scheduler performance. Standardization 
between experiments was maintained by executing all task sets 
over ten cycles where a cycle being defined as the least 
common multiple of all periods in the task set. 

1. Experiment l 

This experiment was designed to determine under what 
load the scheduler started to breakdown, or miss process 
deadlines. The task set consisted of six processes at a 
frequency of 10 Hz. Figure 5.3 shows that scheduler breakdown 
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began to occur at a 90% load, close to the maximum predicted 
by [SHA 90] . 




The processor load was varied by increasing or decreasing , 
process execution times while maintaining constant process 
frequencies. Initial processor load was 50% and increased at 
5% intervals upto 110%. Processor loads over 100% were 
included to study scheduler stability characteristics. 

2. Experiment 2 

This experiment replaced one of the 10 Hz processes in 
the first task set with a 20 Hz process. The sample run 
consisted of the same processor loads as the first experiment. 

As shown in Figure 5.4, the results were quite different from 
the first experiment. 
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Figure 5.4 Performance for One 20 Hz Process and Five 10 Hz 

Processes 

The earlier break down was explained, theoretically, as being 
due to the increased overhead caused by the increased number 
of task swaps incurred by the higher frequency process. After 
more experimentation, it was determined that the highest 
practical frequency for a process is 10 Hz. If higher 
frequencies are required, processor loads must be limited to 
no more than approximately 50%. 

3. Experiment 3 

This experiment determined the number of lower 
frequency processes that could be executed successfully. 
Figure 5.5 shows four different task sets consisting of eight 
tasks each, with the number of 10 Hz processes varying from 
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zero to three. The remaining processes are executed at 5 Hz. 
Processor loads were the same as in the first two experiments. 
It is interesting to note that while all task sets broke down 
at approximately the 90% point, the breakdown was accelerated 
proportional to the number of higher frequency processes 
present. The various task groups are represented as follows: 
solid line, eight 5 Hz tasks; dashed line, one 10 Hz task plus 
seven 5 Hz tasks; dotted line, two 10 Hz tasks plus six 5 Hz 
tasks; combination dotted and dashed line, three 10 Hz tasks 
plus five 5 Hz tasks. From this it was determined that the 
scheduler is more greatly affected by task frequencies than by 
task execution times. 




Figure 5.5 Performance with Different High Frequency 

Processes 
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4 . Experiment 4 

This experiment was an attempt to devise and execute a 
'typical' task set for the vehicle. A typical set being one 
that could be expected to be found on AUV-II during a normal 
mission. This set was constructed after discussion with 
project members who were developing software modules for 
guidance, control and sonar. The set consisted of eight 
processes; two at 10 HZ, four at 5 Hz, and two at 2 Hz. The 
results are plotted in Figure 5.6. 




Figure 5.6 Performance for a Typical Task Set for AUV-II 



5. Experiment 5 

This experiment was an attempt at developing a task set 
that more realistically represented actual vehicle operation. 
The same task set was used as in experiment 4 with randomized 
execution times included. A random number generator was added 
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to each child process along with the logic needed to apply a 
normal distribution curve to the execution times. This code is 
given in Appendix C. The distribution was such that 50% of the 
executions were run at the mean time of execution; 40% of the 
executions were run at +/- 10% of the mean time; the remaining 
10% of the executions were run at +/- 20% of the mean time. 
The lower utilization rate shown in Figure 5.7 was 
predictable. A process cannot ’save* excess allotted time from 
shorter than expected executions to make up for the longer 
than expected executions later encountered. 




% processor load 

Figure 5.7 Performance for a Typical Task Set with Variable 

Execution Times 



6. Experiment 6 

This experiment was virtually the same as experiment 5 
with slight variations in the periods and execution times. 
Figure 5.8 shows the results of the changed task set and is 
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included to show the breakdown qualities of the scheduler 
during sustained overload. The 'staircase' pattern was 
predicted prior to the experiment and was caused by preemption 
of the various lower priority processes. The more nearly 
vertical lines are caused by deadlines missed. When the graph 
first levels, all deadlines in the lowest priority process 
have been preempted, but all higher priority processes are 
still meeting their deadlines. The graph began to move upward 
again when the next lowest priority process began to miss 
deadlines . 




% processor load 

Figure 5.8 Scheduler Stability Under Sustained Overload 



This 'shedding' of lower priority processes would continue 
until only the highest priority process is still executing. 
This orderly break down ensures stability and allows for more 
efficient and safe vehicle operation under sustained overload 
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conditions. 



The experiments reported are a representative subset of a 
much larger number of sample runs made to establish scheduler 
reliability and performance. As can be seen by these results 
the scheduler objectives listed in Chapter I have been met in 
all cases and the scheduler, as implemented, can be considered 
sophisticated enough for the present needs of AUV-II. 
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VI. CONCLUSIONS AND FUTURE RESEARCH 



A. CONCLUSIONS 

The primary objective of this research was to provide an 
efficient, hard real-time scheduler for the AUV that would be 
capable of maintaining a reasonably high processor utilization 
rate. This was to be accomplished over the varying group of 
task sets that the vehicle could be expected to encounter. 

As implemented, the scheduler provides reliable, real-time 
scheduling with utilization rates above 80% for almost all 
variations of task sets. Under worst case conditions, and with 
varying task set execution times, a 75% utilization rate was 
not difficult to achieve. If care is used in developing the 
task set to be used, the system operator should have little 
trouble achieving utilization rates of 80% or higher. 

Aperiodic events can also be handled with the current 
implementation, although not as smoothly as with periodic 
events . 

As per the original specifications, the scheduler is 
stable under overload. Lower priority tasks are always 
suspended before higher priority tasks during overload 
conditions, so a subset of the most critical processes always 
meet their deadlines. Of course, the critical subset varies 
with processor load. 
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B. FUTURE RESEARCH 



Although the scheduler meets all original specifications 
and should serve well into the future of the project, several 
modifications could be made to improve its performance and 
capabilities. These could include the following: 

1. A more sophisticated approach to aperiodic events. The 
current method works well, but will not cover all 
possible eventualities. An alternative method was 
proposed in chapter V of this thesis. 

2. Period transformation may be implemented to deal with 
long period processes that need a high priority. 

3 . A graphical interface could be included that allows for 
a running record of processor utilization, breakdown, and 
overload conditions. 

4 . A user-producer algorithm could be implemented to deal 
with the problem of dependent processes. 

5. Once the appropriate compiler is available from GESPAC, 
the software should be translated from C to Ada to more 
accurately reflect Department of Defense policies. 

6. Once Transputer boards are installed, modifications will 
be needed to allow the scheduler access to the increased 
resources available. 

7. Finally, if an increase in utilization rates are 
required, a hybrid scheduling policy combining RMS and 
dynamic priority assignment may be implemented. 
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APPENDIX A. STARTUP MODULE SOURCE CODE 



/* Program: START_SCHED. C 

Purpose: To assign highest priority to scheduler 
Author: LT Brent L. Leatherman 20 MAY 1991 

*/ 

#include <stdio.h> 

#include <errno.h> 

#include <procid.h> 

/* the following function are all OS-9 specific */ 

extern int wait (), os9forkc (), exit (), intercept () ; 
extern char **environ; 



/* the following is the structure required to fork a process 
the process to be forked MUST reside in the CMOS directory 
as a compiled, executable module -NOT LINKED- with any 
other module. 

*/ 

char *argl[]={ 

"rate_mono", /* this line in the structure contains */ 
0,); /* the name of the process to be forked */ 

/* the following is the dummy intercept handler required when 
forking a process */ 

icpthand(signum) 
int signum; 

{ 

/* intercept handler */ 

} 

main ( ) 

{ unsigned status; /* used in wait command */ 

intercept (icpthand) ; 

/* following is process creation */ 

os9exec (os9forkc, argl [0] , argl, environ, 0,62000,3) 

wait (Sstatus) ; /* suspend process until signal is 

received from scheduler */ 
printf ( "Received signal from proc %d\n" , status) ; 

/* completion message to sysop */ 
exit(O) ; /* END PROGRAM */ 

} 
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APPENDIX B. SCHEDULER MODULE SOURCE CODE 



/* 



*/ 



Program : RATE_MONO . C 

Purpose: To collect task set parameters, prioritize 
the task set, determine task set 
schedulability, and then to carry out the 
scheduling policies. 

Author: LT Brent L. Leatherman 15 APRIL 91 

Theory: Based on rate monotonic scheduling theory 
[SHA 90] 



# include 
# include 
# include 
# include 
# include 
#include 



<stdio.h> 

<math.h> 

<errno.h> 

<procid.h> 

<setsys.h> 

<signal .h> 



/* constants */ 

/*SIZE determines number of tasks in set */ 
#define SIZE 15 



/* MAX_PRIORITY determines most critical tasks priority */ 
#define MAX PRIORITY 60000 



/* The following functions are all OS-9 specific functions. 
Kill 0 ,Exit() & Wait() all deal with signals 
OS9forkc(), InterceptO & Environ deal with process 

creation 



*/ 



Sleep deals with process timing 

getpidO & _get_process_desc () deal with process 

characteristics 



extern 

int 

kill ( ) , os9forkc ( ) , exit () , wait ( ) , sleep ( ) , intercept ( ) , 
getpidO ,_get_process_desc( ) ; 
extern char **environ; 
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/* This structure contains the required process 
characteristics needed for process creation. A blank line is 
required to hold the name of each process that will be created 
*/ 



/* each line is 10 characters long - the */ 
/* length of the name of the process with*/ 
/* no '.C appended. The number of lines */ 
/* must equal the variable SIZE */ 



0 , 

}; 



char *argl[]= 

{ 

II II 

/ 

II II 

t 

II II 

t 

II II 



/* The same structure as argl, used in the process of timing 
individual processes by measuring the execution time of a 
modified process named the same as before with an 'a' appended 
to the executable module */ 

char *arg2[]= 

{ 

II II 

t 

II II 

t 

II II 

t 

II II 

t 

II II 

i 

II II 

i 

II II 

i 

II II 

t 

II II 

t 

II II 

t 

II II 

f 

II II 

t 

II II 

f 

II II 

I 

II II 

t 

0 , 

); 
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/* the following procedure is a duminy intercept handler that 
OS-9 requires when returing from a fork command */ 

icpthand ( signum) 
int signum; 

{ 

/* intercept handler */ 

} 



main () 

{ 

FILE *file; /* output file for signal recording */ 

/* the following variables are the various loop controls 
required. The variable n, however, is the number of tasks in 
the task set. /* 

int m,z,t,p,i, j ,k,l,n, 
count, 

mask, /* used to mask off top end of time stamp */ 
tickl, /* used to hold value of tick from time */ 
tick2; /* holds second tick value for comparison */ 



double T[SIZE], /* task set periods */ 

C[SIZE] , /* task execution times */ 

W[SIZE] [SIZE] , /* holds intermediate values in 

schedulability tests. See [SHA 86]. 

*/ 

Li [SIZE] [SIZE] , /* next set of intermediate values. 

*/ 

Lint[SIZE], /* holds values when converting from 

continous to discrete quantities */ 
L; /* the final value, if <= 1.0, the set is 
schedulable */ 

sched_pt [SIZE*2 ] , /* holds scheduling point values 

arbitrarily twice the maximum 
number of processes */ 

temp, terml, tempi, temp2,chk; /* simple holding 

variables */ 

int LCM, /* the least common multiple of all periods */ 
process_pri [SIZE] , /* process priorities */ 
LCM_ARR[5*SIZE] ;/* used in the calculation of the LCM 

arbitrarily set to 5 times the number 
of processes */ 
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double SCOREBOARD[SIZE] [2 ] ; /* a table containing periods 

and pids for all processes */ 

unsigned status, svalue; /* used by OS-9 functions */ 

/* the following are used in the OS-9 timer system to 
determine both elapsed and real-time */ 

int start_sec, start_tick, adjust , date, 

time , tick , t imel , t ime2 , mask2 , sec , index , start_t ime ; 
short sigcode,day ; 

/* the following are used to determine process characteristics 
*/ 



int pid, /* process id # */ 

gpiderr, /* error recorder from fork command */ 
loop_con; /* signal control variable */ 
procid parent; 



sigcode=0x01 ; /* hex signal used to wake a process */ 
pid=getpid ( ) ; /* function to determine process ID */ 
mask=OxOOOOf f f f ; /* hex code used to mask off top four 

bytes of timer variable in order to 
obtain number of ticks from system 
clock */ 



process_pri [ 0 ] =MAX_PRIORITY ; /* set highest priority to 

the most critical task */ 
file=fopen("rate.out", "w") ; /* open file for output */ 

/***★*★★**** *********************************** ********** */ 
/* The following section is input to the program 

primarily task execution time C[] & task periods T[] */ 

/* ***************************************************** */ 

printf ( "Number of forks desired: \n" ) ; /* controls the 
number of signals sent to the called processes. 
Strictly used in the lab. Onboard AUV-II, will need 
to be disabled or set to infinity */ 



scanf ("%d" , &loop_con) ; 
printf ("\n\n") ; 

/* number of processes in task set */ 

printf ( "Number of processes to schedule: ( <=15 )\n"); 

scanf ( "%d" , &n) ; 

/* following loop brings in task set parameters */ 
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d\n", (i+1)) ; 



for ( i=0 ; i<n ; i++ ) 

{ 

printf ("Enter the name of the process # % 
scanf ("%s",argl[i] ) ; 
for(j=0; j<9; j++) 

arg2[i] [ j ]=argl[i] [ j ] ; 
strcat (arg2 [i] , "a") ;/* used for process timing */ 
print f ("Enter the period of process # 

%d (ticks) \n", (i+1) ) ; 
scanf ("%F" , Stemp) ; 

/* OS-9 eccentricity - scanf commands MUST use 
capital F vice lower case f */ 

T[i]=temp; 
printf ("\n\n") ; 

printf ("Enter the execution time\n") ; 
scanf ("%F" , Stemp) ; 

C [ i ] =temp ; 

/* the following code (commented out) , if implemented allows 
the timing of the processes to be done by the system vice 
human entry */ 

/* _sysdate (3 , Stime, &date, &day , Stick) ; /* OS-9 timer 

call */ 

printf ("Starting second is %d\n",time); 

/* get start time of process creation */ 

tickl=(tick S mask) ; /* getting time in ticks */ 
timel=time*100+tickl ; /* accounts for tick rollover 

on the second */ 

intercept (icpthand) ;/* dummy procedure needed prior 

to fork */ 

/* creation of a process */ 

os9exec(os9forkc,arg2 [i] , arg2 , environ, 0 , 63000,3) ; 
wait(O) ;/* scheduler waits for completion of process 

*/ 

/* get end time of process call */ 

_sysdate ( 3 , Stime , Sdate , Sday , Stick) ; 
tick2=(tick S mask) ; 
time2=(time*100+tick2) ; 

/* following is elapsed time calculation */ 

C [ i ] =time2-timel ; 

C[i]=C[i]-40;/* correction factor for fork overhead 

*/ 

end of self timing sequence */ 

/* the following alerts sysop that timing is complete 
and reports the results of the timing */ 

printf ("**** Process # %d timing ****\n" , (i+1) ) ; 
printf ("execution time is: % . lf\n" , C [ i] ) ; 
pj^ifitf (••************************* * *\n" ) t 
printf ("\n") ; 
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) 



^ -k ***************************************************** *y 

/* The following code sorts the matricies C[] & T[] in 
descending order based on process execution times ( C[] ). 
This is done by an insertion sort routine. The sort is needed 
later in the program for priority assignment based on process 
execution times. */ 

/* ***************************************************** */ 



for ( i=l ; i<=n ; i++) 

{if (T[i]>T[i+l]) 

(chk=0; 
templ=C[ i] ; 
temp2=T[ i] ; 
for(j = (i-l) ; j>=l;j — ) 
{C[j+l]=C[j]; 
T[j+l]=T[j] ; 
if (T[ j-l]<=temp2) 
{C[ j ]=templ; 

T[ j ]=temp2 ; 

j=i; 

chk=l; 

) 

) 

if (chk!=l) 

(C[1]=C[0] ; 
T[1]=T[0] ; 

C[ j ]=templ; 

T[ j ]=temp2 ; 

} 

} 



/* end sort routine */ 

^ -k ***************************************************** */ 

/* the following code computes the scheduling points as 
described in Chapter IV. The points are stored in the array 
sched_pt[] */ 

^k **************************************************** k^ 

count =0 ; 

for ( i=0 ; i<n ; i++) 

( 

for(j=0; j<=i; j++) 

{ 

for(k=l;k<=floor(T[i]/T[ j ] ) ;k++) 

{ 
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f lag=0 ; 

S=k*T[ j ] ; 

f or (p=l ;p<count ;p++ ) 

{ if (S==sched_pt [p] ) 
flag=l; 

} 

if (flag==0) 

{ 

sched_pt [ count ] =S ; 
count++ ; 

} 

} 

} 

} 



/* ***************************************************** */ 
/* The following code computes the Wi(t) as described in 
chapter IV of this thesis. */ 

/* **************************************************** */ 
terml=0 ; 

for ( i=0 ; i<n ; i++) 

{ 

f or ( t=0 ; t<count ; t++ ) 

{ 

for ( j=0; j<i; j++) 

{ 

terml=terml+C[ j ] *ceil (sched_pt[t]/T[ j ] ) ; 

} 

W[ i] [t]=terml ; /* Eqn (4.2) */ 

terml=0 ; 

} 

} 

/* ****************************************************** */ 
/* The following code computes the Li term as described in 
equation 4.3 in chapter IV */ 

/* ***************************************************** */ 

for (i=0;i<n;i++) 

{ 

for ( t=0 ; t<count ; t++ ) 

{ 

Li[i] [t]=(W[i] [t]/sched_pt[t] ) ; /* Eqn (4.3) */ 

) 

) 
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/* *********************************************** */ 

/* The following code finds the minimum Li for (0<t<Ti) as 
described by eq. 4.4 of chapter IV. */ 

/* *********************************************** 

*/ 



for ( i=0 ; i<n ; i++) 

Lint[i]=10000;/* arbitarily large number*/ 

for ( i=0 ; i<n ; i++) 

{ 

for (t=0 ; t<count ; t++) 

{ 

if (Li[i] [t]<Lint[i]) /* Eqn (4.4) */ 
Lint[i]=Li[i] [t] ; 

) 

} 



*************************************************** *y 
/* The following code computes the maximum value of Li. If 
this value is less than, or equal to 1 the task set is 
schedulable, else it can not be done. This routine will also 
tell the user how much excess processor time is left */ 

y* *************************************************** * y/ 

L^O f 

for ( i=0 ; i<n ; i++) 

{ 

if (Lint[i]>L) 

L=Lint [ i] ; 

) 

U=0; /* determines processor load */ 

for ( i=0 ; i<n ; i++) 

U=U+C[i]/T[i] ;/* if processor load >1.0, not sched.*/ 
if ( (L<=1) & (U<=1) /* Eqn 4 . 5 */ 

printf ("Process set schedulable. \n\n") ; 
if ( (L>1) 1 I (U>1) ) 

printf ("Process set not schedulable\n\n") ; 
printf ("Total remaining processor time is; 

%.2f", (1-U) *100) ; 
printf (" percent\n\n\n\n") ; 



y* *************************************************** * y 
/* The following code computes the least common multiple of 
the periods of all processes in the task set in order to 
calculate relative priorities. */ 

y ■k *************************************************** */ 
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temp=l ; 

for (1=0 ; l<n ; 1++) 

temp_per iod [ 1 ] =T [ 1 ] ; 

for (l=0;l<n;l++) /* scan list for prime numbers */ 

{ 

/* check for even divisors using modulo arithmetic */ 

for ( k=0 ; k<n ; k++ ) 

{ 

if ( (1 ! =k) & (temp_period[ 1] %temp_period[k]==0) ) 
temp_period[l]=l; /* check for divisibility */ 

) 

} 

for ( 1=0 ; l<n ; 1++ ) 

{ 

m=temp_period [ 1 ] ; 
count=0 ; 

for ( i=2 ; i<=m; i++) 

{ 

if ( (m%i) ==0) 

{ 

f lag=0 ; 

for ( j=0; j<count; j++) 

( 

if (i==LCM_ARR[ j ] ) 

flag=l;/* recording LCM points */ 

} 

if ( flag==0) 

{ 

LCM_ARR [ count ] =i ; 

count++;/* how many LCM points */ 

} 

m=m/ i ; 
i=2; 

) 

} 

for (k=0 ;k<count ;k++) 

{ 

temp=temp*LCM_ARR[k] ; 

LCM_ARR[k]=0; 

) 

} 

LCM=temp ; 

/* end of LCM routine */ 



/* ****************************************************** */ 
/* The following code assigns priorities to the scheduled 
processes. The processes with the shortest execution time have 
the highest priorities as per [SHA 90] . The exact priority is 
assigned in accordance with an equation (4.1) */ 

/* ***************************************************** */ 
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ternp=l ; 
temp 1=0 ; 
temp2=l; 

for (i=l; i<n; i++) 

{ 

for (j=0; j<=(i-l) ;j++) 
temp2=temp2 *T [ j ] ; 
for(k=0;k<=(i-l) ;k++) 

{ 

for (1=0 ; 1<= ( i-1) ;1++) 

{ 

if (ll=k) 

temp=temp*T[l] ; 

) 

templ=templ+C[k] *temp; 
temp=l ; 

} 



process_pr i [ i ] =process_pr i [0]- 

ceil (LCM* (templ/temp2) *5*i) ; 
/* Eqn (4.1) */ 

temp 1=0 ; 
temp2=l ; 

) 

temp 1=0 ; 

for ( i=0 ; i<n ; i++) 

(if (T[i]>templ) 
templ=T[ i] ; 

} 

for ( i=l ; i<n ; i++) 

process_pr i [ i ] =process_pri [ 0 ] - ( i*templ) ; 



/* end of priority assignment routine */ 

/* following code prints statistical messages to a file on 
disk - a compilation of task set parameters */ 

fprintf (file, "process#\texec. time\t period\t\tpriority\n") ; 
fprintf (file, •' \t \t \t\t \n") ; 

for ( i=0 ; i<n ; i++ ) 

(fprintf (file, " %d",(i+l)); 

fprintf (file, •' %.lf",C[i]); 

fprintf ( file, ” % . If ” , T[ i] ) ; 

fprintf (file, ” %d\n”,process_pri[i] ) ; 

) 

fprintf (file, ''\n\n\n\n\n\n” ) ; 
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y* ****★★★★*★★■*★★★★★■*★★*★******★★★★★★★★*★■*★■*★ *y 
/* the following loop is an infinite while loop that will 
control the processes to be forked off. A "scoreboard" 
type approach used in that when a process is signaled, 
it's next execution time is computed and scheduled. Psuedo- 
code for this procedure may be found in figure 4.3. */ 

/* ******************************************* */ 

count=0 ; 

_sysdate (3 , &time, &date, &day , Stick) ; /* get time */ 
tickl=(tick & mask) ; 

pid=getpid ( ) ; /* get process id number */ 

adjust=0 ; 

for ( i=0 ; i<n ; i++) 

{ 

intercept (icpthand) ; /* dummy intercept handler */ 
os9exec(os9forkc,argl[i] , argl, environ, O,process_pri[i] , 3) ; 
_get_process_desc (pid, sizeof parent, Sparent) ; 

SCOREBOARD[i] [0]=T[i] ; /* enter original period in 

table */ 

SCOREBOARD[i] [l]=parent._cid; /* enter process id */ 
printf ("process id # %d is %d\n" , (i+1) , parent ._cid) ; 
printf ( "rate_mono pid is: %d\n",pid); 



while (count < loop_con) /* infinte loop when in vehicle */ 

{ 

sec=0 ; 

for ( i=0 ; i<n ; i++ ) 

(if (SCOREBOARD[i] [0]==0) 

{ INDEX [sec]=i ; /* record values */ 
sec++ ; 

} 

y* *★***********★****★*★★★******★★** 

/* find all processes with zero time */ 

/* left. This indicates that they */ 

/* are ready for execution. These */ 

/* are recorded in INDEX. */ 

/* ********************************* */ 

} 

_sysdate (3 , Stime, Sdate, &day, Stick) ; 
tickl=(tick S mask) ; /* start time */ 
for ( z=0 ; z<sec ; z++) 

{ 

sigcode=SCOREBOARD[ INDEX[z] ] [ 1] ; /* get process id 

that is to be signaled */ 
kill (sigcode, 1) ; /* send wake up signal */ 
count++; /* counts number of signals sent */ 

} 

_sysdate ( 3 , St ime , Sdate , Sday , Stick) ; 
tick2=(tick S mask) ; /* end time */ 
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if ( tick2<tickl) 
tick2=tick2+100 ; 

adjust=tick2-tickl; /* time used in signaling process 

*/ 

/* the following code reassigns original period to signaled 
processes */ 

for ( i=0 ; i<sec ; i++) 

SCOREBOARD [ INDEX [ i ] ] [ 0 ] =T [ INDEX [ i ] ] ; 

/* the following code subtracts the time used in signaling 
from all processes */ 

for ( i=0 ; i<n ; i++ ) 

SCOREBOARD[i] [0]=SCOREBOARD[ i] [ 0] - (adjust-1) ; 
temp=10000 ; 

for (i=0 ; i<n; i++) /* find shortest time to execution 

*/ 

if (SCOREBOARD[i] [0]<temp) 
temp=SCOREBOARD [i][0]; 

for (i=0 ; i<n ; i++) /* subtract smallest time */ 

/* from all periods /* 

SCOREBOARD [ i ] [ 0 ] =SCOREBOARD [ i ] [ 0 ] -temp ; 

^ -k 'kk'k'k’k’k'k'k'kk'k'kkk’k'k'k'k'k'k'kkk'k'k'k'k'k'k'k'k'kk'k’k'k'k'k'k'kk'k'k'k'k'kkk'k'k'k'kkk k ^ 

/* the next code puts 'main* to sleep for the shortest 
period remaining in the table. */ 

/* ****************************************************** */ 

if (temp <=0) 

fprintf ( file, "problem with temp\n") ; 

/* OS-9 eccentricity. If tsleep is used with the value 0 
(zero) or below, it goes to sleep forever, system 
reboot is required to restart system. */ 

if (temp>0) 

( svalue=ceil (temp) ; 
tsleep (svalue) ; 

/* system suspension to allow execution of 
signaled processes */ 

) 

} 

/* ***************************** */ 

/* end of fork coding */ 

/****************************** */ 



/* the following code allows for an orderly, gracful end to 
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the scheduler. It kills all active processes, returning all 
resources back to the system manager. */ 

fclose (file) ; 
tsleep(lOOO) ; 
for(i=0;i<n;i++) 

(sigcode=SCOREBOARD[i] [1] ; 
kill (sigcode, 0) ; 

) 

exit (pid) ; 

/* END PROGRAM */ 

) 
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APPENDIX C. MODIFICATIONS TO CALLED MODULES 



/* Program: 
Purpose: 



Author: 



PROCi.C 

To illustrate a dummy process used in 
experimental verification of the scheduler, 
and the modifications necessary to function with 
the implemented scheduler. 

LT Brent L. Leatherman 12 MARCH 1991 



# include <stdio.h> 

# include <errno.h> 

#include <signal.h> 

#include <setsys.h> 

/* following functions are OS-9 specific */ 

extern int exit() ; 
extern char **environ; 

main ( ) 

{ 

FILE *file; /* needed for statistical dump following 

execution */ 

int date, time, tick, mask; /* needed to access system 

clock */ 

short day ; 

int z,k,i; /* loop control variables */ 

int hold_time[ 100] [4 ] ; /* holds start and stop times */ 
int count; 

mask=0x0000ffff ; /* mask used to get time in ticks */ 
count=0; /* counts number of signals received */ 
z=l; 

/* The following is the infinite loop modification required 
by the scheduler. It needs to encompass all code that is 
to be executed each time and NOT initialization commands 
that are to be done only once. If the self-timed module 
execution option is being used, this loop should be 
removed so that an accurate timing of one execution is 
recorded. */ 

while (1) 

{ 

printf ("prod count = %d\n", count); /* msg to sysop */ 
_sysdate ( 3 , &time, &date, &day , Stick) ; /* get start time */ 
tick=(tick & mask) ; 

hold_time[ count] [0]=time; /* record start time in 

seconds */ 

hold_time [count] [ l]=tick; /* record start time in ticks 

*/ 
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/* The following is a delay loop used to simulate process 
execution times, replaced by process code on AUV-II . A 
loop count of 3300 equals a time period of one tick, or 
one millisecond. */ 

for ( i=l ; i<3300 ; i++) 
z=z+l ; 

_sysdate(3 , Stime, Sdate, &day, Stick) ; 

tick=(tick S mask); /* find and record finish times */ 
hold_t ime [ count ] [ 2 ] =t ime ; 
hold_time[ count] [3]=tick; 
count++ ; 

/* The following code is needed due to the measurable time 
required to write to a hard disk drive. Therefore, 
instead of writing each time as it comes in, the times 
are recorded and then written in a batch at the users 
discretion using modulo arithmetic on the variable count. 
In this example, times are recorded every 20 signals */ 

if ( (count%20) ==0) 

/* the following are the statistical outputs */ 

{ 

f ile=fopen ( "outl" , "a" ) ; 

fprintf (file, "stats for process #2\n") ; 
for ( z=0 ; z<count ; z++ ) 

{ 

fprintf (file, "proc 2 start time: 

%d . %d\n" , hold_time [ z ] [ 0 ] , hold_time [ z ] [ 1 ] ) ; 
fprintf (file, "proc 2 end time: 

%d . %d\n" , hold_time [ z ] [ 2 ] , hold_time [ z ] [ 3 ] ) ; 

} 

fclose(file) ; 
count=0 ; 

} 

) 

exit(O) ; 

/* END PROGRAM */ 

} 
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/* Program: PROCj.C 

Purpose: To demonstrate the random number generator added 
to vary execution time. The rest is identical to 
the first dummy procedure. 

Author: LT Brent L. Leatherman 12 MARCH 1991 

*/ 

#include <stdio.h> 

# include <errno.h> 
finclude <signal.h> 

#include <setsys.h> 

extern int exit() ; 
extern char **environ; 

main( ) 

{ 

FILE *file; 

int date, time, tick, mask; 
short day; 
int z,k,i; 

int hold_time[100] [4] ; 
int count, next, 
rand_num, 

length, /* nominal execution time */ 
lengthl, /* execution time -20% */ 
length2, /* execution time -10% */ 
lengths, /* execution time +10% */ 
length4 ; /* execution time +20% */ 
mask=0x0000f f f f ; 
count=0 ; 
z=l; 

_sysdate ( 3 , & t ime , Sdate , &day , Stick) ; 
next=(tick S mask) ; 

lengthl=2666 ; /* various execution times */ 
length2=3000; 
length3=3666 ; 
length4=4000; 
while (1) 

{ 

length=3333; /* nominal execution time */ 

/* random number generator */ 

/* initial seed comes from system clock */ 

next=next*1103515245+12345; 
rand_num= ( (next/65536) % 32768); 
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/* The following code sets up the distribution pattern, as 
follows : 

5% of the time execution time is -20% 

20% of the time execution time is -10% 

50% of the time execution is nominal 
20% of the time execution time is +10% 

5% of the time execution time is +20% 

*/ 

if (rand_num<0) 

rand_num=rand_num* (-1) ; 
if (rand_num<1638) 
length=lengthl ; 

if ( (rand_num>=1638) & (rand_num<8191) ) 
length=length2 ; 

if ( (rand_num>=24574 ) & (rand_num<31127) ) 
length=length3 ; 
if (rand_num>=31127) 
length=length4 ; 

printf ( "proclO count = %d\n", count); 

_sysdate ( 3 , &time , Sdate , &day , Stick) ; 
tick=(tick & mask); 
hold_time [count] [0]=time; 
hold_time[ count] [l]=tick; 
for ( i=l ; i<length ; i++) 

2 =z+l ; 

_sysdate (3 , Stime, Sdate, &day , Stick) ; 
tick=(tick S mask) ; 
hold_time[ count] [2]=time; 
hold_time[ count] [3]=tick; 
count++ ; 

if ( (count%20) ==0) 

{ 

file=fopen("outl" , "a") ; 

fprintf (file, "stats for process #2\n") ; 
for ( z=0 ; z<count ; z++) 

{ 

fprintf(file,"proc 2 start time 
%d. %d\n" ,hold_time[ z ] [ 0 ] ,hold_time[ z ] [ 1] ) ; 

fprintf ( file, "proc 2 end time 

%d . %d\n" , hold_time [ z ] [ 2 ] , hold_time [ z ] [ 3 ] ) ; 

} 

f close ( file) ; 
count=0; 

) 



) 

exit (0) ; 
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APPENDIX D. OS-9 SPECIFIC REAL-TIME PRIMITIVES 



The following is a list of real-time primitives supported 
by the OS-9 operating system. All descriptions come from 
[MICROWARE 87], 

- os9forkc; used to create a process 

- exit: used to terminate a process 

- wait: used to suspend process until a signal is received 

- sleep: used to suspend a process for a specified number 

of seconds 

- tsleep: used to suspend a process for a specified number 

of ticks 

- alm_atdate: used to send signal at specified Gregorian 

date 

- alm_atjul: used to send signal at specified Julian date 

- alm_cycle: used to send signals at constant intervals 

- alm_set: used to send a signal after a specified elapsed 

time 

- kill: used to delete a process 

- abort: used to stop process from keyboard 

- wake: used to place suspended process on ready to 

execute queue 
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